Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

samjo's recipe-muncher #32

Open
wants to merge 59 commits into
base: master
Choose a base branch
from
Open

samjo's recipe-muncher #32

wants to merge 59 commits into from

Conversation

sjlee3157
Copy link

@sjlee3157 sjlee3157 commented Nov 5, 2018

API Muncher

Congratulations! You're submitting your assignment!

Comprehension Questions

Question Answer
How did you go about exploring the Edamam API, and how did you try querying the API? I used curl and Postman to help me explore the API.
What is an API Wrapper? Why is it in lib? How would your project change if you needed to interact with more than one API (aka more than just the Edamam API)? The API Wrapper limits the interface of the Edamam API and my app in order to isolate dependency. I think it's in lib because it's not part of the Rails MVC architecture. My app does interact with more than one API if you count OAuth strategies and the Google People API. Omniauth is doing most of the "wrapper" work for me, but if it wasn't, I would be creating another wrapper class and figuring out how to parse the JSON/XML responses.
Describe your API wrapper, the methods you created in it, and why you decided to create those methods/how they were helpful I created these methods: self.list_recipes, self.get_recipe, self.list_tags, and the self.build_recipe factory method. The methods were necessitated by the structure of the Edamam API, which just happens to accept GET requests formatted in specific ways that I addressed in my methods.
What was an edge case or failure case test you wrote for your API Wrapper? What was a nominal case? Edge: trying to "get" a result from Edamam API with a bogus recipe id. Nominal: trying to get a result with a valid recipe id.
How does VCR aid in testing an API? VCR records and plays back API calls which is useful because API calls are often limited, expensive, and unreliable!
What is the Heroku URL of your deployed application? https://hello-munchy.herokuapp.com

Trello: https://trello.com/b/HL0gtltd/sj-api-muncher
See Trello for what remains to be done. I'm not finished with testing, but a lot of what's left is testing that I've practiced with MR-R and bEtsy. While TDD is a good practice, for this project I decided to prioritize learning new skills, like OAuth Google and filtering search results.

@dHelmgren
Copy link

API Muncher

What We're Looking For

Feature Feedback
Core Requirements
Git hygiene yes
Comprehension questions good
General
Rails fundamentals (RESTful routing, use of named paths) Yes!
Semantic HTML That Index page has a lotta divs.
Errors are reported to the user Mostly see comment on Index testing.
API Wrapper to handle the API requests yes
Controller testing Pretty good see comments
Lib testing good!
Search Functionality yes
List Functionality yes
Show individual item functionality yes
Styling
List view shows 10 items at a time and/or has pagination yes
Attractive and usable UI so so. I think the flippy recipe cards are great, I had a hard time spotting your search bar.
API Features
The App attributes Edamam You need to attribute it on every page. This is really important! When you're designing code for money, using someone else's work without attribution is a good way to end up in legal trouble.
The VCR cassettes do not contain the API key yes!
External Resources
Link to deployed app on Heroku Yes
Overall This is a good showing! You hit the learning goals very well, just make sure that your Attributions are complete in the future.

get "/auth/:provider/callback", to: "sessions#create", as: 'auth_callback'
delete "/logout", to: "sessions#destroy", as: "logout"

resources :recipe_searches, only: [:index, :show]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work setting these with resources

attr_reader :label, :recipe_uri, :source, :source_uri, :ingredient_lines,
:image_uri, :recipe_yield, :total_time, :health_labels

REQUIRED_ARGS = [:label, :recipe_uri, :source, :source_uri, :ingredient_lines]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say you're over-validating here. In general, you should only validate fields that will cause your app to break if they're not there. In this case, that's label, uri and possibly image. Anything beyond that is an unnecessary dependency on the data coming from the API and is an extra thing for you to test.

recorded_at: Wed, 31 Oct 2018 22:22:23 GMT
- request:
method: get
uri: https://api.edamam.com/search?app_id=<EDAMAM_APP_ID>&app_key=<EDAMAM_APP_KEY>&r=http://www.edamam.com/ontologies/edamam.owl%23bogus!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay!


describe FavoritesController do
it "should get index" do
get favorites_path

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some interesting cases you're not covering here:

  • What happens if no search term is provided?
  • What if the search returns no results?

It might also be worthwhile to add some tests around the paging parameters:

  • What happens if they're absent?
  • Do you get different results when they change?
  • What if you send a bogus value, like a negative page number?

Just FYI, Your pagination breaks if I give it a negative page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants